Skip to main content
Expert Talk
Amakomaya — Aamako Maya Apps Pvt. Ltd.

Health Information Exchange

Health information exchange is the movement of clinical information between organisations that do not share a system: a hospital and a district health office, a laboratory and a clinic, a private provider and a national registry.

"An HIE" refers to the whole apparatus — the technical infrastructure, the participation agreements, the governance body and the operating team. It is an institution more than a piece of software, and programmes that procure only the software discover this late.

What it has to solve​

Regardless of architecture, four problems must be answered:

  1. Identity — is this the same person, facility and clinician on both sides? (registries)
  2. Discovery — where does information about this patient exist?
  3. Retrieval — how is it obtained, in what format, with what latency?
  4. Authorisation — is this requester permitted this data, for this purpose, with this patient's consent?

An architecture is largely determined by how it answers 2 and 3.

The three structural models​

Centralised​

A single repository holds the clinical data. Source systems push to it; queries are served from it.

   EMR A ──┐
   EMR B ──┼──push──▶  ┌────────────────────┐  ◀──query── Consumers
   Lab   ──┤           │ Shared health      │
   CHW   ──┘           │ record (central)   │
                       └────────────────────┘
StrengthsFast, predictable queries. Works when sources are offline. Enables population analytics directly. Simple to operate.
WeaknessesData duplication and staleness. Concentrated privacy risk and a single high-value target. Requires the legal basis for central storage. Sources may resist relinquishing custody.
SuitsCountries with clear central mandate; environments with unreliable connectivity at the edge; when analytics is a primary goal.

Federated​

Data stays with the source. A registry records where information exists; the exchange queries sources at read time and assembles the response.

                     ┌──────────────┐
   Query ───────────▶│  Record      │  "who holds data on this patient?"
                     │  locator     │
                     └──────┬───────┘
                            │ fan-out query
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
           EMR A         EMR B          Lab
              │             │             │
              └─────────────┴─────────────┘
                      assembled response
StrengthsSources keep custody, which is often the only politically acceptable answer. No stale copies. Smaller central privacy footprint.
WeaknessesQuery latency is bounded by the slowest source. Every source must be online and highly available. Population analytics is hard. Debugging is distributed.
SuitsMulti-institution networks with strong data-custody norms; good connectivity; regulatory environments prohibiting central storage.

Hybrid​

The usual real answer. A central index and a curated summary set are held centrally; full records stay at the source and are fetched on demand.

  Sources ──push summary──▶ ┌─────────────────────┐
                            │ Central: identity,  │◀── fast queries
                            │ index, summary set  │
                            └──────────┬──────────┘
                                       │ on-demand fetch of detail
                            ┌──────────┴──────────┐
                            ▼                     ▼
                          EMR A                  Lab

The summary set is typically the International Patient Summary shape: problems, medications, allergies, immunisations, key results. It is what a clinician needs in an unplanned encounter, and it is small enough to keep current.

StrengthsFast for the common case; custody preserved for the detail; resilient when a source is down (the summary still answers).
WeaknessesTwo mechanisms to build and operate. Requires deciding what belongs in the summary — a clinical governance question, not a technical one.
SuitsMost national architectures.

See the full pattern write-up in centralised vs federated HIE.

Exchange styles​

Orthogonal to the structural model: how information moves.

Document exchange​

A whole, attested clinical document — discharge summary, referral letter — is published and later retrieved. IHE XDS/XCA (or MHD over FHIR) provides the registry/repository infrastructure; content is CDA or a FHIR document Bundle.

Good for: referral and discharge, legal attestation, low-trust or low-bandwidth transport, offline transfer. Poor for: answering "what is this patient's current creatinine?" — you must find and open the right document.

API-based exchange​

Query for the resources you need. FHIR REST is the dominant form.

Good for: targeted queries, apps, decision support, incremental adoption. Poor for: attestation, and situations where the source cannot host an API.

Event-based exchange​

Sources publish events — admission, result available, notifiable diagnosis — and interested subscribers receive them.

Good for: surveillance, care coordination, keeping an index current, triggering workflow. Poor for: as the sole record of truth. Events are notifications; always pair with a reconciliation query. See event-driven interoperability.

Patient-mediated exchange​

The patient carries or authorises access to their own record — a SMART on FHIR app, a QR-coded summary, a personal health record.

Good for: cross-border care, mobile populations, ecosystems with no legal basis for provider-to-provider sharing, and consent legitimacy. Poor for: emergencies where the patient cannot participate, and populations without devices or literacy to manage it.

Bulk exchange​

Scheduled transfer of large volumes for analytics or migration — FHIR Bulk Data.

Good for: warehouses, quality measurement, research. Poor for: anything at the point of care.

Most ecosystems eventually use four of these five. The mistake is choosing one and forcing every use case through it.

Discovery patterns​

PatternHow it finds dataNotes
Registry-basedA record locator lists which sources hold data for a patientThe standard federated approach (IHE XCA, XDS registry)
Broadcast queryAsk every sourceSimple; does not scale beyond a handful, and leaks the fact of the query
Central indexCentral store knows what it holdsFastest; requires central storage
Patient-providedThe patient names or authorises the sourcesStrong consent story; incomplete by nature

The record locator is itself sensitive. Knowing that a patient has records at an HIV clinic is a disclosure even if no clinical data is retrieved. Access to the locator needs the same controls as the data.

Design decisions to record​

Each of these deserves an ADR:

  • Structural model — centralised, federated, hybrid
  • What the central summary set contains, and who decides
  • Consent model — opt-in, opt-out, purpose-based — and break-glass
  • Identity strategy and matching thresholds
  • Standards and versions, with an upgrade policy
  • Latency and availability targets, and edge behaviour when unmet
  • Audit retention and who may query the audit log
  • Onboarding and conformance requirements for participants
  • Funding model for the shared components
  • Exit — how a participant leaves and what happens to its data

Why they fail​

Observed repeatedly, in roughly descending order of frequency:

  1. No legal basis for sharing, discovered after the build
  2. Identity was assumed — no registry, so records cannot be matched
  3. Built before there was a consumer — a write-only repository
  4. Terminology never mapped, so pooled data cannot be analysed
  5. No sustainable funding for the operating team after the grant ends
  6. Participation was voluntary with no incentive — the largest providers opted out
  7. The pilot's champion left

Note how few of these are technical.

References​

Last updated on